A software design framework is an architectural pattern that provides an extendable template for applications. In the context of object-oriented computer software, a framework provides a set of classes that can be extended via sub-classing or used directly to solve a particular problem within a particular problem domain. A set of objects implemented within the set of classes then works together to carry out responsibilities within the particular problem domain and a family of applications.
One example of the object-oriented framework architecture is a concept of a container. A container provides an execution environment for components that cannot execute alone.
Containers interact with contained components through predefined interfaces. A class from the set of classes implements an interface by either implementing the interface's methods directly, or inheriting implementations from superclasses. Instances of such classes can be woven into a tree of objects within the limits of assembly rules hard-coded in the various classes. Such a tree of objects is called an object graph. Object graphs are the software representation of some real-world problem to be modeled in a computer.
An object-oriented framework architecture is described in U.S. Publication No. 2002/0059467 entitled “Object-Oriented Framework Architecture for Sensing and/or Control Environments.” Another object-oriented sensing and control framework is described in U.S. Publication No. 2002/0184348 entitled “Object-Oriented Framework Architecture for Sensing and/or Control Environments.”
In prior art object-oriented programming, the assembly and execution of object graphs is based on code that weaves components together in a rigid way based on a static model. However, this static model does not provide flexibility because a software developer is required to extend, delete, replace or rearrange the object graph's components. In addition, object graphs are typically closed once built. They can only be modified at runtime within hard-coded constraints, their structure cannot be examined, and arbitrary locations in the graph cannot be interrogated for data. Therefore, it is desirable to have an object assembly and execution life cycle model that allows properly constructed objects to be assembled in a flexible declarative manner.
The prior art does not disclose or suggest the use of fractal like containers to describe and manipulate models of physical entities in a time domain, using an object assembly and execution life cycle model that allows properly constructed objects to be assembled in a flexible declarative manner.